Bound decoder work to prevent a pointer fan-out DoS (STF-1488) - #281

A crafted data section could nest pointers to shared targets so that
decoding one record cost exponential time and memory from a small file
(GHSA-hj94-g986-h9r7).

The pure PHP decoder now limits the number of values it decodes for a single
record and rejects a database that exceeds the limit with an
InvalidDatabaseException. The limit is 65,536, far above the few hundred
values the largest real records decode. Pointer cycles and over-deep data
are rejected the same way rather than exhausting the stack. This matches the
reader resource limits now recommended by the MaxMind DB specification.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The value and depth limits stop the pointer fan-out, but not payload
amplification: an array of pointers to one large string or bytes value
keeps the value count low while a reader that copies each target
materializes the value once per pointer. A file of a few hundred
kilobytes can force gigabytes.

Add a second, independent per-lookup limit that bounds the total string
and bytes payload copied for one decode to 2 MiB, matching libmaxminddb
and the Go reader. The byte budget is charged wherever a string or bytes
value is decoded, including inline inside a pointed-to container, so a
shared target recharges each time it is followed. This also covers a
pointer-backed map key, which decodes through the same path. The budget
is call-local and passed by reference, so concurrent lookups do not
share state.

Also reject a fixed-width scalar whose declared size exceeds 16 bytes
before the bytes are read, so an oversized variable-length integer
cannot amplify the read.

Both new limits reject with the existing InvalidDatabaseException, so
there is no public API change and no behavior change for valid records.

Bump the test-data submodule for the payload-amplification fixtures and
add regression tests for each attack shape.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The changelog described only the value, depth, and payload limits. State
the two other user-observable effects of the same fix: the decoder rejects
a scalar whose declared length is more than 16 bytes, and all of the limits
apply to the metadata read when a database is opened.

Also correct a comment in Decoder.php. The remaining types are not all
fixed-width scalars: the container (12) and end-marker (13) types and any
unknown extended type also reach that point, where the size guard or the
default case rejects them.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The DoS tests in ReaderTest assert the pure-PHP decoder's messages, so
they cover only that path. When the maxminddb extension is loaded, Reader
decodes through libmaxminddb, which has its own copy of the limits, and
nothing asserted that path rejects the DoS fixtures.

Add extension-path checks that decode each DoS fixture through the loaded
extension and assert an InvalidDatabaseException. The limits live in
libmaxminddb, so the checks first probe a fixture one byte over the 2 MiB
payload limit, which is small and safe to decode. A libmaxminddb with the
fix rejects it with the decoder-limit message and the checks run; an older
one decodes it and the checks skip, rather than run the large DoS fixtures
through a decoder that would exhaust memory.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

These tests assert the pure-PHP decoder's "exceeds the maximum payload
size" message. When the maxminddb extension is loaded, Reader decodes
through libmaxminddb, which reports different text, so the assertions
failed. They also fed the large amplification and fan-out fixtures to the
extension's decoder, which on a libmaxminddb without the fix would exhaust
memory.

Skip them when the extension is loaded. The extension path is covered
safely by ExtensionDosTest, which probes a small fixture first and runs the
large fixtures only against a libmaxminddb that enforces the limits.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>